COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.run: NEWSEC RUNTIME OVERVIEW, CONTROL STRUCTURES
C00009 00003	.NEWSS DATA STRUCTURES
C00014 ENDMK
C⊗;
.run: NEWSEC RUNTIME OVERVIEW, CONTROL STRUCTURES

	The runtime is a  set of programs residing in  the PDP-11. We
will discuss control structures and data structures.

.NEWSS CONTROL STRUCTURES

	There are several  types of processes any number of which can
be active at any time:

.UNFILL
	1) Interpreters
	2) Joint servos
	3) On-monitors
.REFILL

	An INTERPRETER is a process which is executing  arithmetic or
other stack-oriented instructions,  not one of the moves. Most 
straightforward  HAL  code  is  executed  by  interpreters.    During
execution of COBEGIN blocks, or while the conclusion of an ON-monitor
is running, there can be more than one interpreter.

	Each  active  interpreter has  a  stack  on  which it  places
operands, a program counter which  points to its particular block  of
code, and a  list of those  on-monitors for which it  is responsible.
Each  interpreter  also  has  a  reserved  cell  in which  it  stores
information concerning its current location in  the source  code; this  is
useful  for  debugging.    The  code  which  it  interprets  includes
instructions   for   stack   manipulation,   arithmetic   operations,
instantiation of  subsidiary interpreters, flow  of program  control,
and preparation for  motions.  As soon as a  move is encountered, the
active  interpreter  instantiates  the  required  joint  servos   and
on-monitors and  waits  for the  termination  of the  move
before continuing.

	A JOINT  SERVO is a process whose task  is to servo one joint
of a moving arm, according to the planned trajectory for  that joint.
When finished,   the servo  stops the joint  and disappears.   If the
joint  should be stopped by  some other process,  the servo cleans up
the mess and dismisses.
	During its life, the servo is in charge of applying to one
motor the correct current, which  will change over time.  The correct
signal is calculated based on the planned location of the joint,  its
observed location and velocity, and  its recent positional error.
After emitting  the proper drive, the servo  precalculates as much as
it can for some future time, when it will again modify the drive, and
then waits for that future time to arrive.

	An ON-MONITOR is a process  which continually checks for some
condition.   If  that condition  should appear,   then  those actions
specified by  the compiler  as critical  are done  immediately (in  a
non-interruptible  fashion); for the  rest,   the monitor  sprouts an
interpreter.   The  ON-monitor can  be  in two  states:  enabled  and
disabled.  The  checking is only  done while the monitor  is enabled.
A monitor disappears only when the system kills it.
	An  enabled  on-monitor  can be  of  two  types: hardware  or
software. The  hardware type  is a  true interrupt  handler that  can
react to some hardware condition.  An example of this is a monitor to
detect something hitting the touch pads on the fingers.  The software
type is a  set of calculations which  are to be repeated  frequently,
the  result of  which is  a decision  whether or  not to  trigger the
conclusion of the monitor.

	These  various  types  of   processes  are  scheduled  by   a
combination of priority structure and  time-slot request disciplines.
Joint  servos are critical  in the  sense that the  calculations they
make are highly  time-dependent; they  must be guaranteed  not to  be
interrupted.    Therefore,  they  operate at  a  very  high  software
priority.  On-monitors are less critical, and they operate at a lower
priority.   Interpreters  run at  the lowest  priority.   Both  joint
servos  and   on-monitors  are  tasks  which  need   to  be  awakened
periodically.  Therefore, time  is divided into  slots one
millisecond  wide.   One  servo and  any  number of  on-monitors  can
reserve  a time  slot; when  that  time arrives,  the servo  is given
guaranteed  control,   and  when   it  terminates,   all   requesting
on-monitors are allowed to use the time remaining in the slot.  After
all  these critical  requests are satisfied,  any running interpreter
uses the time left over until the next slot begins.
	
	Appendix  II describes  the  instructions  available  to  the
interpreter,  the tables  emitted for  motions, the  nature  of joint
servos, and  the  priority  interrupt  and  scheduling  structure  in
greater detail.
.NEWSS DATA STRUCTURES
.NEWSSS	VALUE CELLS

	Values are stored in cells; each datatype has its own
format for the value cell.  Fixed-point numbers are used throughout.

	Scalars are stored in a single word, in fixed-point format.

	Vectors are  stored in  four consecutive  words.  The  fourth
entry  is usually 1; the  arithmetic routines are  optimized for such
normalized vectors.  To normalize a vector, divide each entry  by the
fourth one.

	Planes  are also  stored  in  four words.    The first  three
represent  an outward-facing  normal,  and the  last is  the negative
distance to the (table) origin.

	Frames are stored as 4x4 arrays,  by columns.   
In addition,
  there are 6  words set aside for the joint  angles
associated  with the  frame,
that is, the angles necessary for one of the arms to reach that point
in space.  There are a few bits to tell which arm is meant and whether
the joint angles are valid, that is, whether they have been calculated
since last the frame's value was changed.
Joint angles are  calculated  only if
needed.  This  happens if the  frame is being  used as  a point in  a
trajectory.

	Transes are stored in two 4x4 arrays: One holds the trans itself,
and the other  the inverse.

.rgf: NEWSSS	GRAPH STRUCTURES

	Variables are  allocated "node  cells".   These cells have  a
pointer to the value cell, as  well as other fields used
in graph structure manipulation.

NODE CELL
.BEGIN INDENT 0,8;TABBREAK; PREFACE 0; NARROW 8;
	invmark -- =0 if value is valid, otherwise invalid (note: the
evalnode algorithm  uses a "time" to detect  cycles.  Therefore, this
field needs to be (at least) 16 bits.
	value -- pointer to a value cell.
	calculator -- points to a list of calculator cells
	changer -- points to a block of interpretable code. There are
a few  special-purpose changers which do  not point to any  code, but
are used as shorthands. 
	dependents -- points to a list of dependents
	type -- encoding (in several bits) of datatype.
.END

CALCULATOR CELL

.BEGIN INDENT 0,8;TABBREAK; PREFACE 0; NARROW 8;
	link -- link to next on the chain (there can be more than one
calculator for a node).
	needed  --  points  to list  of  variables  needed  for  this
calculator. The dependents cell format is used for the needed list.
	code -- points to a block of interpretable code.
.END

DEPENDENTS CELL

.BEGIN INDENT 0,8;TABBREAK; PREFACE 0; NARROW 8;
	link -- link to next on the chain (there can be more than one
dependent of a node).
	dep -- points to the node cell of one dependent.
.END

	The algorithms used to extract values from and insert values
into the graph structure are described in Appendix II.